[doc](security) Add threat model for scans#63447
Conversation
### What problem does this PR solve? Issue Number: N/A Related PR: N/A Problem Summary: Add an explicit Apache Doris threat model and root agent guidance so security scans, security reviews, and vulnerability triage classify findings using the project scope, trust boundaries, attacker roles, explicit non-goals, and out-of-model or by-design categories. ### Release note None ### Check List (For Author) - Test: No need to test (documentation-only change) - Behavior changed: No - Does this need documentation: No
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
|
/review |
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
There was a problem hiding this comment.
I found two issues in the new threat-model document that should be fixed before it becomes the root guidance for security review and triage. The model otherwise appears focused and consistent with the PR goal, but these two points can lead to ambiguous version binding or incorrect triage assumptions.
Critical checkpoint conclusions: Goal: the PR adds a canonical threat model and root guidance; it mostly accomplishes this, but the missing model-version field and incomplete env-var inventory weaken the triage contract. Scope/minimality: documentation-only and focused. Concurrency/lifecycle: not applicable except for documented security process lifecycle; version lifecycle needs the explicit field. Configuration items: no runtime config added, but the document describes config/env behavior and should match code. Compatibility/storage/transactions/data writes: not applicable. Parallel paths: FE and BE env handling both need to be reflected, including config substitution paths. Tests: no tests needed for docs, but factual claims were checked against code. Observability/performance/memory: not applicable for this docs-only change. User focus: no additional user-provided focus points were supplied.
|
|
||
| - **Project**: Apache Doris (https://doris.apache.org) | ||
| - **Model version binding**: written against `master` at commit | ||
| `1d1846591f7`, 2026-05-14. Per M15 (single-living-doc policy), the |
There was a problem hiding this comment.
This says triage is keyed by a model-version field at the top of the file, but the file being added does not contain such a field. Since this PR also updates AGENTS.md to make threat-model.md the first document used for vulnerability triage, leaving the version identifier as a follow-up makes the version-binding rule impossible to apply or automate for this initial accepted v1.0 document. Please add the top-level model-version field now, or weaken this paragraph until the field exists.
| atomic intrinsics; FE assumes the JMM. Neither is signal-safe. | ||
| - **Filesystem**: BE assumes ownership of `storage_root_path` | ||
| directories; concurrent external mutation is undefined. | ||
| - **Network**: cluster-internal network is treated as a security |
There was a problem hiding this comment.
The runtime environment-variable inventory is too narrow for the current code. For example, BE reads additional hard-coded variables such as DORIS_CLASSPATH in be/src/util/jni-util.cpp, SKIP_CHECK_ULIMIT in be/src/storage/storage_engine.cpp, and AI_TEST_RESULT in be/src/exprs/function/ai/ai_functions.h; FE deployment code also reads deployment-specific env names in fe/fe-core/src/main/java/org/apache/doris/deploy/DeployManager.java. More importantly, both FE ConfigBase.replacedByEnv() and BE config::replaceenv() expand arbitrary ${...} names from config files via System.getenv() / std::getenv(). Because this statement is part of the security contract, triagers may incorrectly close env-based reports as out-of-model. Please either include these paths/variables or rephrase this as a non-exhaustive list and explicitly mention config-driven env expansion.
What problem does this PR solve?
Issue Number: N/A
Related PR: N/A
Problem Summary: Add an explicit Apache Doris threat model and root agent guidance so security scans, security reviews, and vulnerability triage classify findings using the project scope, trust boundaries, attacker roles, explicit non-goals, and out-of-model or by-design categories.